MySQL双主模式设计 | 您所在的位置:网站首页 › MySQL主从切换 不断业务 › MySQL双主模式设计 |
1. 适用场景
很多企业刚开始都是使用MySQL主从模式,一主多从、读写分离等。但是单主如果发生单点故障,从库 切换成主库还需要作改动。因此,如果是双主或者多主,就会增加MySQL入口,提升了主库的可用性。 因此随着业务的发展,数据库架构可以由主从模式演变为双主模式。双主模式是指两台服务器互为主 从,任何一台服务器数据变更,都会通过复制应用到另外一方的数据库中。
高可用架构如下图所示,其中一个Master提供线上服务,另一个Master作为备胎供高可用切换, Master下游挂载Slave承担读请求。
MMM(Master-Master Replication Manager for MySQL)是一套用来管理和监控双主复制,支持双 主故障切换 的第三方软件。MMM 使用Perl语言开发,虽然是双主架构,但是业务上同一时间只允许一 个节点进行写入操作。下图是基于MMM实现的双主高可用架构。 MMM故障处理机制 MMM 包含writer和reader两类角色,分别对应写节点和读节点。 当 writer节点出现故障,程序会自动移除该节点上的VIP写操作切换到 Master2,并将Master2设置为writer将所有Slave节点会指向Master2除了管理双主节点,MMM 也会管理 Slave 节点,在出现宕机、复制延迟或复制错误,MMM 会移 除该节点的 VIP,直到节点恢复正常。 MMM监控机制 MMM 包含monitor和agent两类程序,功能如下: monitor:监控集群内数据库的状态,在出现异常时发布切换命令,一般和数据库分开部署。agent:运行在每个 MySQL 服务器上的代理进程,monitor 命令的执行者,完成监控的探针 工作和具体服务设置,例如设置 VIP(虚拟IP)、指向新同步节点。 3. MHA架构MHA(Master High Availability)是一套比较成熟的 MySQL 高可用方案,也是一款优秀的故障切换和 主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在30秒之内自动完成数据库的故障切 换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的 高可用。MHA还支持在线快速将Master切换到其他主机,通常只需0.5-2秒。 目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务 器。 MHA由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。 MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台 slave节点上。负责检测master是否宕机、控制故障转移、检查MySQL复制状况等。MHA Node运行在每台MySQL服务器上,不管是Master角色,还是Slave角色,都称为Node,是 被监控管理的对象节点,负责保存和复制master的二进制日志、识别差异的中继日志事件并将其 差异的事件应用于其他的slave、清除中继日志。MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的 slave提升为新的master,然后将所有其他的slave重新指向新的master,整个故障转移过程对应用程序 完全透明。 MHA故障处理机制: 把宕机master的binlog保存下来根据binlog位置点找到最新的slave用最新slave的relay log修复其它slave将保存下来的binlog在最新的slave上恢复将最新的slave提升为master将其它slave重新指向新提升的master,并开启主从复制MHA优点: 自动故障转移快主库崩溃不存在数据一致性问题性能优秀,支持半同步复制和异步复制一个Manager监控节点可以监控多个集群 4. 主备切换主备切换是指将备库变为主库,主库变为备库,有可靠性优先和可用性优先两种策略。 主备延迟问题 主备延迟是由主从数据同步延迟导致的,与数据同步有关的时间点主要包括以下三个: 主库 A 执行完成一个事务,写入 binlog,我们把这个时刻记为 T1;之后将binlog传给备库 B,我们把备库 B 接收完 binlog 的时刻记为 T2;备库 B 执行完成这个binlog复制,我们把这个时刻记为 T3。所谓主备延迟,就是同一个事务,在备库执行完成的时间和主库执行完成的时间之间的差值,也就 是 T3-T1。 在备库上执行show slave status命令,它可以返回结果信息,seconds_behind_master表示当前 备库延迟了多少秒。 同步延迟主要原因如下: 备库机器性能问题 机器性能差,甚至一台机器充当多个主库的备库。分工问题 备库提供了读操作,或者执行一些后台分析处理的操作,消耗大量的CPU资源。大事务操作 大事务耗费的时间比较长,导致主备复制时间长。比如一些大量数据的delete或大表DDL操 作都可能会引发大事务。可靠性优先 主备切换过程一般由专门的HA高可用组件完成,但是切换过程中会存在短时间不可用,因为在切换过程中某一时刻主库A和从库B都处于只读状态。如下图所示: 可用性优先 不等主从同步完成, 直接把业务请求切换至从库B ,并且让 从库B可读写 ,这样几乎不存在不可 用时间,但可能会数据不一致。 通过上面介绍了解到,主备切换采用可用性优先策略,由于可能会导致数据不一致,所以大多数情 况下,优先选择可靠性优先策略。在满足数据可靠性的前提下,MySQL的可用性依赖于同步延时 的大小,同步延时越小,可用性就越高。 |
CopyRight 2018-2019 实验室设备网 版权所有 |